-
Notifications
You must be signed in to change notification settings - Fork 67
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Klib support #183
Klib support #183
Conversation
f80179f
to
0a2d44f
Compare
cac5669
to
5ba0dbe
Compare
Input klib dump files were not tracked as merger dependencies, so the merged dump was not updated when apiDump was re-executed after sources update
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't look at the implementation itself, but I decided to post comments now, because they were pending for too long
/** | ||
* Specify which version of signature KLib ABI dump should contain. | ||
*/ | ||
public var signatureVersion: Int = 2 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why this setting need to be exposed to end users? Can't we infer it from klib file itself?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can, that's for sure. But when the default/latest version will change, old dumps will be invalid. So there should be a way to specify a particular version.
But here we should probably use some latest-version-available
alias instead of the concrete version 2
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't get it. If the klib version changes, it means .klib.api
file format (not actual signatures) would also change? That looks undesirable. Probably we should have some intermediate parser layer that would provide stable output.
Also, if klib version changes to 3, but user has signatureVersion = 2
it means that we parse klib v3 but output should look like 2. Which brings us again to some middle-layer transformation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A klib may have multiple signature versions. For example, each declaration may have both v1 and v2 signatures.
The signature is a part of a dump we're producing, so when it changes, the dump also change.
Probably we should have some intermediate parser layer that would provide stable output.
Not sure how we can do that. Signatures are part of a declaration as a linker looks up for symbols by their signatures. And there may be no direct mapping between different signature versions and a declaration they belong to.
Also, if klib version changes to 3, but user has signatureVersion = 2 it means that we parse klib v3 but output should look like 2. Which brings us again to some middle-layer transformation.
We parse the same klib, but instead of dumping v2 signature, will dump v3 signature.
A klib's dump with v1 signature:
https://github.com/Kotlin/binary-compatibility-validator/blob/f5fdacf4d2e9548144f522aa2924742ac4e473f5/src/functionalTest/resources/examples/classes/TopLevelDeclarations.klib.v1.dump
The dump of the same klib using v2 signature:
https://github.com/Kotlin/binary-compatibility-validator/blob/f5fdacf4d2e9548144f522aa2924742ac4e473f5/src/functionalTest/resources/examples/classes/TopLevelDeclarations.klib.dump
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, v3 actually can't link with v2 because they're incompatible? But newer klibs will have both 3 and 2 sets for backwards compatibility?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, v3 actually can't link with v2 because they're incompatible?
Yes, the linker won't be able to lookup symbols.
But newer klibs will have both 3 and 2 sets for backwards compatibility?
There's no v3 on the horizon right now, so it's hard to tell.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The docs here should guide user when to rely on the default value and when to set it to a fixed value.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Set the null
as a default, mentioned that a user should not care about the option by default.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ilya-g @sandwwraith are you ok with how the version is currently declared and documented?
* By default, ABI dumped only for supported files will be validated. This option makes validation behavior | ||
* stricter and treats having unsupported targets as an error. | ||
*/ | ||
public var strictValidation: Boolean = false |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't these values be of type Property<Boolean>
to support some Gradle configuration feature? Was it configuration cache or something else, @shanshin ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Configuration cache seems to work fine with primitive values. But if there's a case where Properties are better, I can change it (note that a parent class, ApiValidationExtension
don't use Property too).
Co-authored-by: Leonid Startsev <[email protected]>
What's new:
|
- fixed naming - simplified some code constructions - swapped the order of KlibTarget fields - updated merged dump's header - removed unsupported targets from target hierarchy
…ure of a node being more or less common
Co-authored-by: ilya-g <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Forgot to submit the last portion of comments
Added experimental Klib ABI dump validation support. Validation could be performed using the Gradle plugin which provides almost the same validation and dump workflow as for JVM ABI validation. Also, a public API was added to allow users who don't want or can't use the plugin to implement their own workflows. --------- Co-authored-by: Leonid Startsev <[email protected]> Co-authored-by: ilya-g <[email protected]> Pull request Kotlin/binary-compatibility-validator#183
Added experimental Klib ABI dump validation support. Validation could be performed using the Gradle plugin which provides almost the same validation and dump workflow as for JVM ABI validation. Also, a public API was added to allow users who don't want or can't use the plugin to implement their own workflows. --------- Co-authored-by: Leonid Startsev <[email protected]> Co-authored-by: ilya-g <[email protected]> Pull request Kotlin/binary-compatibility-validator#183
Added experimental Klib ABI dump validation support. Validation could be performed using the Gradle plugin which provides almost the same validation and dump workflow as for JVM ABI validation. Also, a public API was added to allow users who don't want or can't use the plugin to implement their own workflows. --------- Co-authored-by: Leonid Startsev <[email protected]> Co-authored-by: ilya-g <[email protected]> Pull request Kotlin/binary-compatibility-validator#183
Added experimental Klib ABI dump validation support. Validation could be performed using the Gradle plugin which provides almost the same validation and dump workflow as for JVM ABI validation. Also, a public API was added to allow users who don't want or can't use the plugin to implement their own workflows. --------- Co-authored-by: Leonid Startsev <[email protected]> Co-authored-by: ilya-g <[email protected]> Pull request Kotlin/binary-compatibility-validator#183 Moved from Kotlin/binary-compatibility-validator@ad1bea6
Added experimental Klib ABI dump validation support. Validation could be performed using the Gradle plugin which provides almost the same validation and dump workflow as for JVM ABI validation. Also, a public API was added to allow users who don't want or can't use the plugin to implement their own workflows. --------- Co-authored-by: Leonid Startsev <[email protected]> Co-authored-by: ilya-g <[email protected]> Pull request Kotlin/binary-compatibility-validator#183 Moved from Kotlin/binary-compatibility-validator@ad1bea6
This PR introduces KLib ABI validation support in the BCV plugin.
The brief overview of the design and decisions made is in the corresponding design doc: https://github.com/Kotlin/binary-compatibility-validator/blob/50ebf8b00492d754732e47453b4d8d0351f33baa/docs/design/KLibSupport.md
Providing a programmatic API similar to the
kotlinx.validation.api
API for working with JVM ABI is planned, but this PR does not include it.Besides the design doc mentioned above, the main entry points for reviewing are
binary-compatibility-validator/src/main/kotlin/BinaryCompatibilityValidatorPlugin.kt
Line 370 in cac5669
binary-compatibility-validator/src/main/kotlin/klib/KlibAbiDumpFileMerger.kt
Line 77 in cac5669